System and method for allocating charges away from a tax account

ABSTRACT

A transaction processing system suitable for processing a merchant transaction includes a computer having a processor, a memory, a plurality of connections over a network for receiving and settling the merchant transaction; and a separator module operative to separate funds associated with the merchant transaction. The separator module further includes a revenue settlement module operative to settle a revenue portion of the merchant transaction in favor of a first account accessible over the network, the first account being associated with the merchant; a tax settlement module operative to settle the tax portion associated with the merchant transaction in favor of a second account accessible over the network, the second account being different than the first account; and a fee resolution module operative to resolve fees associated with operation of the tax settlement module, such that an amount equal to the tax portion is settled in favor of the second account.

FIELD OF INVENTION

The present invention relates to systems in support of commerce, and,more particularly, to a transaction processing system that is suitablefor use by merchants, businesses and companies in the restaurant,hospitality, client services, wholesale, and retail industries, tomanage tax and fee payments in connection with each tenderedtransaction.

BACKGROUND OF THE INVENTION

In the retail sector, customers purchase goods and services using cash,credit cards, or debit cards. While some purchases are not subject totaxation, most are. Food and beverage purchases in a restaurant, forexample, can be subject to state and local sales taxes.

For each sales transaction that is subject to taxation, a merchant islegally obligated to pay tax at a rate that is set based on the locationof the retailer. Thus, in New York City, there may be one rate, whereasin a suburban community outside New York City but still in the state ofNew York, there may be a different rate, whereas the same sales mightnot be subject to tax at all in a different state or during astate-sponsored promotional period to encourage shopping.

Merchants are obliged to collect tax from their customers. The collectedtax is subject to voluntary reporting, yet the monies collected areco-mingled with other funds collected from operation of the retailenterprise. Meanwhile, the merchant has operating expenses in connectionwith running the business, such as payroll, inventory, rent,electricity, information services, franchise fees, and so on. It isimportant for the merchant to maintain accurate accounting records sothat the business is not supported by tax revenue that is being held bythe merchant until its next tax payment (typically, a monthly or aquarterly payment).

When the sales transaction is made in cash, the merchant receives moniessufficient to cover the sales price and any taxes collected from thecustomer. When the sales transaction is made by the customer tendering atransaction card (that is, either a debit or credit card), the merchantreceives monies in the form of additions to its bank balance in theamount of the sales price and any taxes collected from the customer.

It would be an improvement in the art of such transaction processing toavoid co-mingling for as many sales transactions as possible. It wouldbe a further improvement in the art if the tax revenue collected from acustomer were not co-mingled with sales revenue collected by themerchant. Still a further improvement in the art would be a system thattransfers to a taxing authority on an automated basis as much of thecollected tax as possible substantially when the merchant's bank accountis credited with the sales transactions with its customers. The presentinvention addresses these and other needs in the art.

SUMMARY OF INVENTION

In accordance with one aspect of the present invention, a transactionprocessing system suitable for a merchant in the restaurant, hospitalityand retail industry includes a computer having a processor, a memory anda connection to a network, a card reader connected to the computer, anda plurality of modules each comprising code that executes in theprocessor. The card reader transfers credit card data from a credit cardof a customer to the memory of the computer in a conventional manner.Among the plurality of modules, there is a check presentation modulewhich is operative to configure the processor to calculate a sales taxassociated with a price of a product sold to the customer. There is alsoan approval module which is operative to configure the processor toobtain an approval against the credit card data in the memory for atleast the price of the product and the sales tax and thereby define anapproved sale transaction. There are also a revenue settlement moduleand a tax settlement module, optionally, as part of a separator module.

The revenue settlement module is operative to configure the processor tosettle a revenue portion of one or more approved sales transactions infavor of a first account accessible over the network and belonging tothe merchant. The revenue portion excludes the sales tax portion.Meanwhile, the tax settlement module is operative to configure theprocessor to settle the sales tax associated with the one or moreapproved sales transactions in favor of a second account accessible overthe network, wherein the second account is different than the firstaccount.

In accordance with further broad aspects of the invention, a transactionprocessing system suitable for processing a merchant transactioncomprises a computer having a processor, a memory, a first connectionover a network for receiving the merchant transaction, and furtherconnections over the network for settling the merchant transaction, anda separator module comprising code which, when executed in theprocessor, configures the processor to separate funds associated withthe merchant transaction received over the first connection.

According to more particular aspects of the invention, the separatormodule can include a revenue settlement module operative to configurethe processor to settle a revenue portion of the merchant transaction infavor of a first account accessible over the network, the first accountbeing associated with the merchant, wherein the revenue portion excludesa tax portion of the merchant transaction; a tax settlement moduleoperative to configure the processor to settle the tax portionassociated with the merchant transaction in favor of a second accountaccessible over the network, the second account being different than thefirst account; and a fee resolution module operative to configure theprocessor to resolve at least one fee associated with operation of thetax settlement module, such that an amount equal to the tax portion issettled in favor of the second account.

In accordance with further aspects of the invention, the fee resolutionmodule can be configured to appropriate funds from an alternative sourceequal to the at least one fee; and augment the second account with theappropriated funds in the event that the at least one fee is drawn fromeither the tax portion or the second account. Furthermore, thealternative source can be the revenue portion, the first account, and/ora predetermined third account. In a further aspect of the invention, thefee resolution module can be configured to isolate the tax portion frombeing subject to a disbursement of the at least one fee during operationof the tax settlement module; and discharge the at least one fee byeither notifying a requester of the at least one fee to draw the atleast one fee from an alternative source or by providing the requesterwith the fee from the alternative source.

In yet a further aspect of the invention, the fee resolution module canbe configured to determine, prior to operation of the tax settlementmodule, a fee resolution estimate representing an amount estimated to beassociated with operation of the tax settlement module; appropriatefunds equal to the fee resolution estimate from an alternative source;and augment the tax portion with the appropriated funds prior to adisbursement of the at least one fee. The fee resolution module can befurther configured to monitor the second account for a predeterminedperiod of time after processing the merchant transaction; and augmentthe second account with funds appropriated from an alternative sourceequal to any fees deducted from the second account after processing themerchant transaction. The transaction processing system can be furtherconfigured to settle, by the revenue settlement module, the revenueportion of a plurality of merchant transactions simultaneously in abatch. Similarly, the transaction processing system can be furtherconfigured to settle, by the tax settlement module, the tax portion of aplurality of merchant transactions simultaneously in a batch.

According to yet another broad aspect of the invention, a method forproviding a transaction processing system suitable for processing amerchant transaction, the system including a computer having aprocessor, a memory, a first connection over a network for receiving themerchant transaction, and further connections over the network forsettling the merchant transaction, and a separator module comprisingcode which, when executed in the processor, configures the processor toseparate funds associated with the merchant transaction received overthe first connection, is described.

In accordance with more particular aspects of the invention, the methodincludes settling, by the separator module executing in the processor, arevenue portion of the merchant transaction in favor of a first accountaccessible over the network, the first account being associated with themerchant, wherein the revenue portion excludes a tax portion of themerchant transaction; settling, by the separator module executing in theprocessor, the tax portion associated with the merchant transaction infavor of a second account accessible over the network, the secondaccount being different than the first account; and resolving, by theseparator module executing in the processor, at least one fee associatedwith operation of the tax settlement module, such that an amount equalto the tax portion is settled in favor of the second account.

In accordance with further aspects of the invention, the method canfurther include appropriating, by the separator module executing in theprocessor, funds from an alternative source equal to the at least onefee; and augmenting the second account with the appropriated funds inthe event that the at least one fee is drawn from either the tax portionor the second account. Furthermore, the alternative source can be therevenue portion, the first account, and/or a predetermined thirdaccount. In a further aspect of the invention, the method can includeisolating, by the separator module executing in the processor, the taxportion from being subject to a disbursement of the at least one feeduring operation of the tax settlement module; and discharging, by theseparator module executing in the processor, the at least one fee byeither notifying a requester of the at least one fee to draw the atleast one fee from an alternative source or by providing the requesterwith the fee from the alternative source.

In yet a further aspect of the invention, the method can further includedetermining, by the separator module executing in the processor, priorto operation of the tax settlement module, a fee resolution estimaterepresenting an amount estimated to be associated with operation of thetax settlement module; appropriating funds equal to the fee resolutionestimate from an alternative source; and augmenting the tax portion withthe appropriated funds prior to a disbursement of the at least one fee.The method can further include monitoring, by the separator moduleexecuting in the processor, the second account for a predeterminedperiod of time after processing the merchant transaction; and augmentingthe second account with funds appropriated from an alternative sourceequal to any fees deducted from the second account after processing themerchant transaction. In still further aspects of the invention, themethod can include settling, by the separator module executing in theprocessor, the revenue portion of a plurality of merchant transactionssimultaneously in a batch. Similarly, the method can include settling,by the separator module executing in the processor, the tax portion of aplurality of merchant transactions simultaneously in a batch.

These and further aspects, features and advantages of the presentinvention will become more apparent from the following detaileddescription when taken in connection with the accompanying drawingswhich show, for purposes of illustration only, a preferred embodiment ofthe present invention.

BRIEF DESCRIPTION OF THE FIGURES

FIG. 1 illustrates a system arrangement in which a merchant machineconnects to a transaction processing module, in accordance with oneembodiment of the invention, prior to processing by a transaction cardprocessor;

FIG. 2 depicts a flow diagram illustrating a process by which salestransactions are managed;

FIG. 3 depicts a customer invoice for a sales transaction that has notclosed;

FIG. 4 depicts a screen shot of an interface configured to be used inconnection with the invention to transfer revenue and tax portions ofone or more sales transactions for discrete, non-comingled processing;

FIG. 5 depicts a flow diagram illustrating a tax settlement process inaccordance with one or more embodiments of the invention;

FIG. 6 depicts a flow diagram illustrating a process by which fees areassessed during certain sales transactions; and

FIG. 7 depicts a flow diagram illustrating a fee settlement process inaccordance with one or more embodiments of the invention.

DETAILED DESCRIPTION OF CERTAIN EMBODIMENTS

By way of overview introduction, the present invention providesimprovements in transaction processing by isolating sales revenue fromany tax collected by the merchant, such as a merchant in the restaurant,hospitality or retail industry. By isolating the sales tax (or any otherapplicable tax or taxes) from the revenue portion of a salestransaction, the merchant can manage its business without risk ofshortfalls that can result by having the sales tax comingled with salesrevenue. This can be a vital improvement for some merchants who are notwell schooled in accounting. Equally important, however, is the factthat the isolated tax stream can be provided to a taxing authority on aper-transaction, per-day, per-week, or per-month basis, for example,rather than on a quarterly basis, which is a great advantage to thetaxing authority. Furthermore, the isolated tax stream can be protectedfrom or otherwise reimbursed for any fees associated with the transferof those funds which have been designated for the taxing authority.

In FIG. 1, a merchant machine 110 comprises a computer system havingnetwork connectivity such as through a wired (e.g., 10/100 Ethernet) orwireless (e.g., IEEE 801.11g) connection to a network 120. The merchantmachine includes a processor, memory, and conventional input/outputdevices such as a touch screen display. Code is loaded or otherwiseaccessible to the processor and executes to configure the processor as apoint of sale device, in the case of POS module 112, or as a transactionprocessor in the case of Batch module 114, or as an editor in the caseof the administrative module 116. Additional modules can be provided, asunderstood by those of skill in the art, so as to support interactivitywith the touch screen or other input/output device, to supportcommunications by and between the modules and over the network 120, tomanage data, backups, reporting, and so on.

For instance, the code that comprises the POS module(s) 112 can comprise“Dinerware,” by Dinerware, Seattle, Wash. This software provides arestaurant POS system featuring ticket handling, order routing, menus,business policies, labor management functionality, and so on. Other POSsoftware can be used in the merchant machine 110 with equal advantage,including, by way of example and not limitation, “PointOS Professional”by PointOS, “Halo” by Vivonet, and “Cash Register Express” by PCAmerica. As another example, the code that comprises the transactionmodule(s) 114 can comprise “Slipstream” by Midnite Express, Inc. ofMyrtle Beach, S.C. The “Slipstream” software provides transactionprocessing system suitable for multiple credit card, gift, and loyaltycard usage, including, in relevant part, batch processing of salestransactions to third-party transaction card processing facilities. Theadministrative module(s) 116 can comprise code that is a part of the POSor batch software, and generally designates functionality that cansupport configuration of the interface including the buttons and theirlabels, password management, licensing, setting of tax rates, pre-setgratuity levels, gift certificate processing, and other settings thatthe merchant might configure and save in a profile associated with aparticular establishment or a chain of retail establishments.

Conventionally, the merchant machine 110 communicates over the network120 to a transaction card processor 130 which receives a sales fileoutput by the merchant machine and processes one or more salestransactions in the sales file so as to credit a merchant account 140(which includes the data 430 in several rows of the interface 400).There are many transaction card processors 130 around the U.S.A. and allover the world that receive such files and perform merchant servicessuch as processing third-party transactions and attending to interchangefees and other service charges, chargebacks and reversals, if any. Forinstance, First Data Merchant Data Services Corporation (“First Data”),5th 3rd, Heartland, American Express CAPN, etc. The merchant account canbe an account at any traditional or online banking institution. Themerchant account 140 is characterized by having a routing number and anaccount number. Together, these numbers enable funds to be directed fromthe transaction card processor 130 to a particular account associatedwith the merchant.

It should be noted that while the embodiment described herein relates tomerchant transactions conducted using a credit card or debit card, as isdiscussed in detail below in relation to FIG. 5, in instances in which acustomer prefers to pay using cash or check the invention can similarlybe performed using a suitably configured transaction processor inaccordance with one or more embodiments of the invention that canprocess cash/check payments.

Turning briefly to FIG. 2, a first portion of a process flow 200 (steps210 through step 270) illustrates a conventional sales transaction by acustomer with a merchant using a credit card or signature-based debitcard. A customer makes purchases at a merchant in a conventional manner.The purchase can be for goods or services. For instance, the purchasecan be food (soup, appetizer, drink) from a restaurant. The customer'schoices are input into a POS system at step 210. In FIG. 3, the POSsystem comprises the aforementioned Dinerware software that is executingfor the benefit of the restaurant, such as in a machine located at thesite of the restaurant. The purchases subtotal to $34.00. At step 220,tax is calculated such as by operation of a check presentation modulecomprising code executing in the machine that implements the POS inrelation to the price of a product sold to the customer for theparticular location of the retailer and/or the customer. The taxes arecalculated (e.g., $3.02), and the calculated amount is added to thesubtotal to yield a total amount due ($37.02 in the illustratedexample).

If the customer tenders cash, the process continues as described belowin connection with FIG. 5. However, when the customer wishes to payusing a transaction card, or several transaction cards as when the costis split among several people, the transaction card is tendered as shownat step 230 by causing the card to be swiped or otherwise read (e.g.,using a near-field RFID technology) or provided to the POS via an inputdevice. More generally, a card reader is connected to the computerproviding the POS functionality and the card reader transferstransaction card data from a credit card of a customer to a memory ofthe computer.

As indicated at step 240, approval of the tendered card is sought suchas by communicating over the network 120 to a transaction card processor130 associated with the particular card that was tendered (e.g., Visa,MasterCard, American Express, etc.). In a conventional manner, the cardprocessor returns a code if the amount sought for approval is within thecredit limit of the credit card, or within the parameters permitted fora debit card, if that was the card that was tendered. In the case ofrestaurants, the approval may be for an amount that exceeds the purchaseamount ($37.02) to ensure that a gratuity (e.g., a 15%-20% overage) canbe approved in case the customer adds a gratuity to the purchase amountas is customary for customers of some merchants. An approval modulecomprising code executing in the machine that implements the POS managesthe actions necessary to communicate an amount to the transactionprocessor for approval against the transaction card data that has beenread into the memory of the POS machine and to receive anacknowledgement of the approval. This amount, namely, at least the priceof the product and the applicable tax or taxes (e.g., local, state,federal, etc.), defines an approved sale transaction. For onlinepurchases, this can also include any associated shipping and/or handlingcosts. The acknowledgements can be stored locally at the merchant siteor remotely, along with the sales transaction details with thatcustomer. Among other data concerning the transaction that can be storedare the following (all of which can be part of a sales file latercommunicated to the transaction processor 130 for settlement):

-   -   [Date]    -   [Time]    -   [Check]    -   [User]    -   [Card]    -   [Card #]    -   [Approval]    -   [Amt.]    -   [Tax]    -   [Tip]    -   [Total]    -   [Tip %]    -   [Merchant]    -   [Other]

If the approval is obtained, then the process flow continues so as toclose the transaction, as indicated at step 250. If approval is denied,the customer may be requested to provide alternate payment information,which can be received by the POS. Upon confirmation of the approval, atransaction closing module comprising code executing in the machine thatimplements the POS operates to fix the total amount of the purchase, anytax, and any gratuities or costs that are being charged to the customer.The transaction closing module can close the sales transaction in anamount up to the approval defined in the approved sale transaction. Thattotal amount, and some or all of the values of the variables listedabove, are included in a row of a table or in a record or other dataobject that is included in a sales file that is communicated over thenetwork 120 to a transaction card processor, typically at the request ofthe merchant, as indicated at step 270. The sales file is sent out, forexample, by interacting with a settlement control 410 that is providedwithin the interface (see FIG. 4), or by any other appropriate form ofelectronic communication.

In accordance with various embodiments of the invention, the term“settlement” can be used to generally refer to the process in which atransaction is accepted for financial settlement between an issuing bankand a merchant's acquiring bank. The settlement process is a complexaccounting process that ensures that interchange rates are applied, allparticipants in the transaction process have their fees applied and arepaid, and the correct banking transfers are initiated to move funds fromthe issuing bank to all the relevant participants in the transaction.

The settlement control is selectable by a user of the transactionprocessing system (e.g., the POS) to trigger a revenue settlementmodule, a tax settlement module, or both, to cause a transmission overthe network to settle the one or more approved sale transactions. Themerchant selects a payment processor, such as one associated with theVisa and Mastercard tenders, for example, by interacting with a checkbox 420 and can, in a batch mode, send all transactions of that tendertype at once, simultaneously (e.g., all of the illustrated transactionsin a batch manager window 400). The sales transaction of FIG. 3 is shownin the first row, row 430-A, of FIG. 4. As will be understood from thedescription that follows, either or both a revenue portion of the salestransaction and applicable sales tax can be sent out by the code of thesettlement module, simultaneously, in a batch.

Referring now to FIGS. 1, 2 and 4, in accordance with a salient aspectof the invention, the sales file is processed by a separator module 150which comprises code executing in a processor of a machine and operativeto separate sales tax from a revenue portion of the sales transactions.It should be understood that the separator module can be executed on themachine that implements the POS, or can execute on a different machineaccessible to the POS over the network 120. For instance, thefunctionality of the separator module can be a hosted solution thatmerchants can subscribe to in order to facilitate transaction cardprocessing in a manner that eliminates co-mingling of sales or otherapplicable tax with operating revenue. The machine providing the hostedsolution can be a machine of the transaction processor or of a thirdparty. In should be noted that in instances where the separator moduleis part of a hosted solution, the POS can provide the separator modulewith the single data file over the network 120 for settling. Ininstances where the separator module is integrated with the POS, theseparator module can process the sales file as described below, and thenprovide two data sets over the network 120 to the transaction processor130 for settlement. In any implementation, the merchant transaction tobe settled can transmit one or more account numbers and routing numbersto be used in the settlement of funds, or the recipient of the salesfile can maintain (e.g., in an encrypted and/or otherwise secure manner)such information that can be retrieved from a data store and accessedusing information in the sales file (e.g., the merchant identifier). Thedata store can be at the transaction processor or at the merchant, suchas in the POS system, for example.

The code of the separator module 150 comprises a revenue settlementmodule that is operative to configure the processor of the machine onwhich it executes to settle a revenue portion of the approved salestransactions included in the sales file. The settlement is in favor of afirst account that is accessible over the network, such as the merchantaccount 140 which belongs to the merchant. The revenue portion of thesales transaction excludes the sales tax, but can include any gratuityor tip, if applicable. (The purchase revenue and any gratuities aremanaged by conventional POS software, so that the merchant can dividetips among waiters and other staff according to their respectivecustomers served, and/or in accordance with other business rules.) Thecode of the separator module 150 also comprises a tax settlement modulethat is operative to configure the processor of the machine on which itexecutes to settle any sales tax associated with the approved salestransactions in the sales file. The settlement in this regard is infavor of a second account accessible over the network, preferably onethat is different than the first account. In one implementation, thesettlement to the second account can be to an account of a taxingauthority 170, such as tax account 160.

Optionally, when the separator module executes within the machine thatimplements the POS, the settlement control 410 can be configured totrigger a transfer to the transaction processor 130 just the revenueportion of the sales transaction(s), while a second control 440 can beprovided and configured to trigger a transfer to the transactionprocessor 130 just the sales tax portion of the sales transaction(s).Each control can be for tenders of one type or another, such asMastercard and Visa on the one hand by selecting check box 450 (asshown) or American Express by selecting check box 460.

At step 280, the separator module executes to provide to the transactionprocessor 130 two data sets, one designated to each of the first andsecond accounts. For instance, the separator module can include arouting number and an account number associated with each of the firstand second accounts to the transaction processor 130. The transactionprocessor is thereby enabled to settle the transactions in the separatedsales files to distinct accounts free of any co-mingling of sales taxwith sales revenue.

The revenue settlement module and the tax settlement module each arepreferably in communication with a database so that the transmission tothe transaction processor 130 can forward data useful in settling thesales transactions. In one implementation, the communication to adatabase comprises the communication of the sales file message from themachine 110 of the merchant to the separator module 150. The sales fileor database can provide an identifier of the first account; anidentifier of the merchant that caused the transmission; an amount ofthe revenue portion of the one or more approved sales transactions; anamount of the sales tax associated with the one or more approved salestransactions; a date for each respective one of the one or more approvedsales transactions; a time for each respective one of the one or moreapproved sales transactions; or a selection of these data.

At step 290, the third-party transaction processor receives from theseparator module 150 at least two data sets, one concerning a revenueportion of one or more sales transactions and a sales tax portion of thesame group of sales transactions. Referring again to the example in FIG.3, if the communication from the separator module 150 is of one salestransaction rather than a batch of transactions, then the POS provides asales file to the separator module and the separator module operates tooutput a divided or otherwise identified version of the sales file withportions suitable for settling both the sales revenue portion (arrow152) and the sales tax portion (arrow 154). For instance, instead ofsettling the amount in the “Total” field as received from the POS, thefields can be remapped so that the Total, which is used by thetransaction processor 130 has, in the case of the revenue portion, thesum of the Amt and Tip columns (and thus excludes the Tax column), and,in the case of the sales tax portion, the Tax column. In anotherimplementation, the fields are unaltered, but the pertinent fields areidentified to the transaction processor for settlement (that is, thereis no re-mapping of the columnar data). In still another implementation,the Tax column data is omitted to cause a recalculation of the Total foruse in settling the revenue portion of the sales transaction(s), and theAmt and Tip column data are omitted to cause a recalculation of theTotal for use in settling the sales tax portion of the salestransaction(s).

Regardless of the approach taken, the transaction processor settles thesales transaction(s) so that the merchant account can receive at step292 the revenue portion (arrow 134) and so that the second account 160(e.g., tax account) can receive the sales tax component (arrow 132) ofthe sales transaction(s) at step 294. As such, the revenue settlementmodule and the tax settlement module can be understood as beingconfigured, in accordance with the invention, to settle the revenueportion of the one or more approved sales transactions and the sales taxassociated with the one or more approved sales transactions free of anycomingling of those respective portions of the amount tendered by acustomer in each closed sales transaction.

As mentioned above, in instances in which a customer prefers to payusing cash or check the invention can likewise be performed to preventcomingling of those respective portions of the amount tendered by acustomer in each closed sales transaction (namely, the revenue portionand the tax portion), by employing a transaction processor configured bycode executing therein to handle cash/check payments in a manner similarto the process described in relation to FIG. 2. For example, turning nowto FIG. 5, at step 510, details of a purchase are input to a POS in aconventional manner. As described in step 220 of FIG. 2, the tax iscalculated such as by operation of a check presentation modulecomprising code executing in the machine that implements the POS basedon the price of a product sold to the customer for the particularlocation of the retailer and/or the customer.

At step 520, when the customer tenders cash or a check, the merchant maystill desire to keep revenue and taxes from comingling. If a check istendered (e.g., a personal check drawing on a personal checking account,a cashier's check, etc.), the checking account details (a routing numberand an account number associated with the customer's form of payment)and the amount tendered are recorded at step 530. In a variation of theforegoing, the purchase can be by credit card, debit card, or otherelectronic payment (e.g., a NFC-enabled device payment) in the mannerdiscussed above in connection with FIG. 2 using the modules discussed inconnection with that Figure, while any further processing in view of thepayment being by cash or check continuing as described here inconnection with FIG. 5.

Recording can be accomplished by using an image capture device, such asa scanner or camera, or by entering the check details manually into thePOS. At step, 540, the account details, as well as the purchaseinformation, are added to the sales file. If cash (dollar bills and/orcoins) is tendered, the purchase information and the amount tendered aresimilarly added to the sales file at step 540.

Continuing at step 550, the sales file is communicated over the network120 to a transaction processor, typically at the request of themerchant. It should be noted that, depending on the system employed bythe POS and the transaction processor handling the payment processing, amerchant may be required to generate separate files for cashtransactions and checking transactions, and process each payment typeseparately if necessary. At step 560, the separator module executes toprovide to the transaction processor two data sets generated from asingle sales file, one designated to each of a first (merchant) accountand a second (tax) account. The first data set can contain an amount tobe transferred to the merchant account, and the second data set cancontain an amount to be transferred to the account of the taxingauthority. For instance, the separator module can provide a routingnumber and an account number associated with each of the first andsecond accounts to the transaction processor. The transaction processoris thereby enabled at step 570 to settle the transactions in theseparated revenue and tax files to distinct accounts free of anyco-mingling of sales tax with sales revenue.

It should be noted that for cash payments, because the merchant alreadyhas “cash-in-hand,” once the cash sales file is separated into two datasets by the separator module, only the tax portion need be transferredfrom an account of the merchant (or a third party, such as a parentcompany) to an account of the taxing authority. Alternatively, however,the second data set representing the revenue portion can be configuredby the separator module to specify zero (additional) dollars to beconveyed.

For check payments, at step 580 the transaction processor can send eachof the data sets received from the separator module via a dedicatedcheck processing network, such as the Federal Reserve's AutomatedClearinghouse (ACH) network to the customer's bank for furtherprocessing. Upon receiving one or both data sets, as described above,the customer's bank will allocate funds from the customer's checkingaccount and transfer those funds to each of the first (merchant) account(step 590) and a second (tax) account (step 595), in accordance with thecontent of the respective data sets. On the other hand, for a cashpayment transaction, only the tax portion from any cash paymentprocessed by the transaction processor is received at the account of thetaxing authority.

As a consequence employing the herein described transaction processingsystem for either credit/debit card based purchases or cash/check basedpurchases, the second account has access to monies associated with a taxportion of the sales transactions at a merchant location substantiallycontemporaneously with the merchant having access to the monies. Whenthe second account is one belonging to a taxing authority, the taxingauthority obtains access to tax revenue on a daily, weekly, bi-weekly,or monthly basis rather than a quarterly basis. The merchant, meanwhilecan be accorded read access to the second account, or another accountthat is linked to payments made through the second account, so as tomonitor the amount of payments made, say, in a given calendar quarter,and so on.

As discussed above, in conjunction with merchant services, an electronicpayment processor such as transaction card processor 130 can processthird-party transactions and attend to interchange fees and otherservice charges, chargebacks and reversals, if any. Such fees are oftenrequested by the merchant's bank, the purchaser's (customer's) bank/cardissuer, the credit card company/network, etc., and are typicallyassessed to the sales transaction as the funds are being transferredfrom the purchaser's account to any account that is to be funded. By wayof example, flow process 600 of FIG. 6 shows one way in which the salestransaction settlement process of FIGS. 1-4 can be affected by theassessment of fees by various parties in the settlement process. At step605, the transaction details of the example sales transaction of FIG. 3are stored in the original sales file (as indicated on row 430A of FIG.4). As discussed above (FIG. 2, step 280), at step 610 the separatormodule 150 can process the sales file so that the revenue portion—thepurchase price and tip totaling $42.00—can be separated into a purchasefile, and the tax portion—totaling $3.02—can be separated into a taxfile. At step 615 the two files can be sent over network 120 to apayment processor such as transaction card processor 130 for furtherprocessing. As discussed in further detail below in relation to method600 of FIG. 6, it should be understood that in alternative embodiments,such as in the hosted solution discussed above, a single data fileincluding the revenue portion and tax portion can be sent by themerchant over network 120 or otherwise provided to the transactionprocessor having a separator module, at which time the revenue portionand tax portion can be separated and processed separately.

At steps 620 a and 620 b, the payment processor distributes the purchasefile and the tax file to Acquirer A (the merchant's bank) and Acquirer B(the Taxing Authority's bank) respectively. Of course it is understoodthat Acquirer A and Acquirer B can actually be the same bank with twoseparate accounts, one for the merchant and one for the TaxingAuthority. An acquirer is typically a bank or other financialinstitution that hosts an account to which funds are ultimately destinedto be deposited at the end of an electronic sales transaction. Thepayment processor therefore provides each Acquirer with the amount to berequested from the issuer of the purchaser's bank/credit card by theAcquirer—indicated in FIG. 6 in parenthesis as ($42.00) and ($3.02),respectively. At steps 625 a and 625 b, Acquirer A and Acquirer B eachsend their respective requests to a card network, and the requests of($42.00) and ($3.02) are then submitted to the Issuer at steps 630 a and630 b. The card network acts as an intermediary between the Acquirer andthe Issuer to authorize and settle credit card transactions, and canprovide payment instructions as required.

Apart from the original transaction having been separated by theseparator module into two files identifying distinct accounts andoptionally distinct banks, the processing of the transaction can proceedin a conventional manner. It should be noted that while in the exampleembodiment described herein approval is sought for the total salestransaction amount prior to any bifurcation by the separator module (seeFIG. 2, step 240), in other embodiments, approval can be sought for eachof the tax portion and the revenue portion after bifurcation by theseparator module. This is appropriate, for example, in instances where acustomer chooses to make a payment using a PIN-based debit card ordebit-linked NFC-enabled device (requiring a customer to enter apersonal identification number at the POS), wherein a singlecommunication is used for both authorization and settlement, rather thanas separate processes.

The Issuer typically charges the merchant an interchange fee for eachamount requested. An interchange fee is a fee paid by a merchant to acredit card issuer and a card network in exchange for accepting andhandling credit card payments, and can be charged as a flat fee and/or apercentage of the requested amount. Interchange fees are commonlycollected by the issuer and shared with the card network. In the exampleof FIG. 6, at step 635 a, Issuer charges Acquirer A an interchange feeof 240 and sends the revised amount—indicated in square brackets as[$41.76]—via the card network to Acquirer A for settlement. Similarly,at step 635 b, Issuer charges Acquirer B an interchange fee of 20 andsends the revised amount—indicated in square brackets as [$3.00]—via thecard network to Acquirer B for settlement.

Once an acquirer receives a revised amount from an issuer, the acquirerthen typically charges the merchant a discount fee. A discount fee is aprocessing fee paid by the merchant to the acquirer to reimburse theacquirer for the cost of processing the credit card payment. In theexample of FIG. 6, at step 640 a, Acquirer A charges the merchant adiscount fee of 150, settles the payment with the merchant's account,and reports the revised amount—now [$41.61]—to the payment processor.Similarly, at step 640 b, Acquirer B charges the merchant a discount feeof 10, settles the payment with the Taxing Authority's account, andreports the revised amount—now [$2.99]—to the payment processor. Thepayment processor thereafter can provide periodic statements (e.g.,monthly, quarterly, etc.) to both the merchant and the TaxingAuthority's bank, reflecting the transactions handled during arespective period.

In this example, the communications to and from the payment processor,the card network, the issuer, and any further intermediaries includeinformation that traces the transaction back to the purchase file andthe tax file, respectively, or comprise modifications to the purchaseand tax files to track the status of the communications. Of course, thisexample does not include fees charged to the merchant by the paymentprocessor for processing the sales transactions, any third-party fraudmonitoring services, etc., which would also typically be subtracted fromthe funds issued by the issuer. It should be noted that even in otherpayment processing network configurations, such as if only one acquirer(for example, Acquirer A) was used initially to request the total amount($45.02) of the funds from the issuer and then the tax portion wasseparated subsequently, there would still typically be fees associatedwith the transfer of those funds from Acquirer A to Acquirer B whichcould result in less than the total tax portion being deposited in theTaxing Authority's account.

Therefore, in accordance with further embodiments of the invention,separator module 150 can further include a fee settlement module (notshown), which comprises code that executes in a processor in order toprovide the full amount of the tax portion of a sales transaction fromthe tax file at step 610 to the tax account 160. The fee settlementmodule operates to configure the processor of the machine on which itexecutes to settle any fees associated with the tax portion in favor ofthe revenue portion of the sales transaction.

Turning now to process flow 700 of FIG. 7, in accordance withembodiments of the invention, in step 705 a sales transaction can beconducted between a customer and a merchant using, for example, a creditcard, as described above in detail regarding the first portion ofprocess flow 200 (FIG. 2, step 210 through step 270). Alternatively, anyother conventional electronic payment method can be employed, such as byusing an NFC-enabled device, an online payment account, etc. Asgenerally described above in relation to FIG. 1, at step 710 themerchant machine 110 communicates over the network 120 to a transactionprocessor which receives one or more sales file outputs by the merchantmachine and processes one or more sales transactions in each sales fileso as to credit merchant account 140 and tax account 160. In accordancewith embodiments of the invention, depending on the configuration of thesystem and merchant/transaction processor network, sales transactiondata can be received at the transaction processor for processing eitheras a single data file including both the revenue portion and the taxportion which is to be separated by the transaction processor asindicated in step 715, or can comprise two data files, each havingalready been separated into the appropriate amounts for the revenue andtax accounts by code executing in a merchant machine, such as themerchant POS, prior to receipt by the transaction processor.

At step 720, the revenue settlement module utilizes code executing inthe processor of the machine on which it executes to settle the revenueportion in favor of merchant account 140. As discussed above, there arelikely to be an assortment of fees associated with the revenuesettlement, including interchange fees, discount fees, fraud-monitoringfees, etc. However, as these fees are drawn from the revenue that flowsfrom the customer to the merchant by the various entities requesting thefees, and as the merchant is responsible for the payment of these fees,no further action is required by the separator module in settling therevenue portion.

At step 725, the tax settlement module utilizes code executing in theprocessor of the machine on which it executes to settle the revenueportion in favor of the tax account. However, unlike with the revenueportion, the merchant is responsible for paying the full amount of thetax portion that has been tendered by the purchaser (customer) duringthe sales transaction, and, in accordance with a salient part of thisaspect of the invention, further code executes to ensure that the fullamount is deposited in tax account 160. In particular, as indicated atstep 730, the fee settlement module comprises code that configures theprocessor of the machine on which it executes to settle any feesassociated with the tax portion so that an amount equivalent to the fulltax portion paid by the purchaser is provided to tax account 160notwithstanding any fees paid in connection with the processing of thecard transaction. The fee settlement module can execute to provide suchfunds in a number of ways, a few of which are described below.

In accordance with embodiments of the invention, the fee settlementmodule can be configured to monitor the tax portion for any feesdeducted during the settlement of the tax portion in favor of the taxaccount (during operation of the tax settlement module). Monitoring canbe accomplished by tracking the stated amount of the tax portion as itis transferred from the Issuer to tax account 160, for example, byreview the processes performed by the tax settlement module.Alternatively or additionally, fee settlement module can monitor taxaccount 160 directly and compare the amount posted to tax account 160with the original tax portion and flag any discrepancies such as bystoring in a memory the amount of the discrepancy and the tax accountinvolved.

If the fee settlement module determines that a fee or fees have beendeducted from the tax portion at any point during the tax settlementprocess (during operation of the tax settlement module), the feesettlement module can appropriate funds equivalent to the fee or feesfrom an alternative source to augment the tax account. The alternativesource can be the revenue portion, in which case funds equivalent to afee total can be diverted to tax account 160 rather than to merchantaccount 140. The alternative source can be merchant account 160, inwhich case funds equivalent to a fee total can be transferred frommerchant account 140 to tax account 160 to compensate for the feesdeducted. Finally, the alternative source can be a pre-determined thirdaccount that is designated to reimburse tax account 160 for any feesdeducted from the fee portion. This can be an alternate account underthe control of the merchant or may be that of a third-party, such as,for example, a third party payment processor that can bill the merchantlater for any fees paid on the merchant's behalf to tax account 160. Inany of these scenarios, the discrepancy that has been flagged can bematched to a user-configurable setting of the particular alternativesource from which to satisfy the discrepancy, and the fee resolutionmodule can initiate a transfer (or instruct a transfer) from that sourcein favor of the tax account.

In accordance with further embodiments of the invention, the feesettlement module can comprise additional code that configures themodule to preemptively assess whether any fees are to be deducted fromthe tax portion by determining a fee resolution estimate. If the feesettlement module is so configured to define a fee amount that is to bededucted from the tax portion during the tax settlement of a givenpurchase transaction, then the fee settlement module subtracts thedefined fee amount from the revenue portion to be requested from theIssuer and adds the defined fee amount to the tax portion. In this case,the tax portion will be processed through the network with sufficientadditional funds to offset any fees to be deducted.

In the example of FIG. 6, the fees owing on processing the tax portionof the purchase transaction amounted to $0.03, and so the data files canbe separated into $41.97 and $3.05 (instead of ($42.00 and $3.02respectively) in order to better ensure that the final amount depositedto Acquirer B's account is the full tax amount of $3.02. However, thecode executing in the fee resolution module can be further configured toaccount for the increase in the tax portion incurring further processingfees, such as in the case in which the tax portion is sizeable, andcause an incremental amount to be transferred beyond the fees due forthe true tax portion to account for the incremental fees due to fundingthe tax portion to net the Acquirer B account at the full tax portionamount (e.g., to ensure $3.02 is funded). Additional processing fees insuch an instance can be incurred based on a number of factors, such asthe type of credit card tendered, the type of bank account(s) involvedin the transaction, which financial institution is being used, theamount tendered, etc. Typically, each credit card company will set ascale or formula by which processing fees are to be assessed. Likewisefor bank accounts, a “small-business” account may have one scale orformula associated with processing fees, whereas a “premium” account mayhave a different scale or formula associated with processing fees forthe same transaction. Finally, different banking institutions may offerdifferent processing fee scales or formulas, for example, as a way ofattracting business. Processing fees may be a set amount, proportional,incremental (linear), exponential, and/or may be based on set ranges,tiers, thresholds, or any combination thereof

The fee resolution module can therefore be further configured to accountfor the increase in the tax portion incurring further processing fees,by assessing the relevant processing fee structures associated with thetransaction, determining whether processing the tax portion will causesuch additional processing fees to be incurred and, if so, calculatingthe expected additional amount and resolving the additional processingfees by one of the methods described herein of fee resolution.

For example, two new cars may be sold for the same price ($27,000.00) byone merchant car dealer to two customers, Purchaser A and Purchaser B.If the sales tax on a new car sold by a merchant car dealer is 4%, thetaxes assessed for each transaction will be $1,080.00. Purchaser A maytender a credit card for which additional processing fees are assessedon a $1.00-per-$100.00 formula for any tax portion above $100.00, with acap at $15.00 in additional processing fees. The additional processingfees in this instance would be $9.00, to compensate for the $980.00above the initial $100.00. Purchaser B, however, may tender a creditcard for which additional processing fees are assessed based on a tieredscale, with the first $1000.00 assessed a flat rate of $10.00 in fees,and each additional dollar assessed a 50 charge, for a total of $14.00in processing fees. Therefore, the fee resolution module can compriseadditional code that configures the module to assess the relevantprocessing fee structures for each credit card tendered, determinewhether processing the tax portion will cause such additional processingfees to be incurred and, if so, calculate the expected additional feesand resolving the additional processing fees by one of the methodsdescribed herein of fee resolution.

In the example above, for each transaction, upon detecting thatadditional processing fees will be incurred based on the credit cardtendered, the fee resolution module is configured to calculate theexpected fees and resolve the transactions accordingly. For the feesassociated with Purchaser A's credit card, the additional processingfees are offset by separating the data files into $26,991.00 and$1009.00 (instead of ($27,000.00 and $1,000.00 respectively), in orderto better ensure that the final amount deposited to the TaxingAuthority's account is the full tax amount of $1,000.00 after the $9.00processing fee is incurred. Likewise, the fee resolution module willresolve the transaction associated with Purchaser B's credit card byseparating the data files into $26,986.00 and $1014.00 (instead of($27,000.00 and $1,000.00 respectively) in order to better ensure thatthe final amount deposited to the Taxing Authority's account is the fulltax amount of $1,000.00 after the $14.00 processing fee is incurred.

The incremental fees may result in a saving of fees in the revenueaccount depending on the applicable fee schedule and the reduction inthe amount in the revenue account. The final amount deposited in taxaccount 160, after operation of the fee settlement module, is equivalentto the amount paid by the customer in tax. This process is particularlyconvenient in embodiments in which the transaction processor receives asingle data file and the separator module then separates the totalamount into the revenue portion and the tax portion, because the definedfees and any incremental fees can likewise be separated and includedwith the tax portion prior to processing as part of a since separatingprocedure, and this can all be performed by the transaction processorwithout human intervention.

In accordance with yet further embodiments of the invention, the feesettlement module can be configured to isolate the tax portion frombeing subject to a disbursement of fees. This can be accomplished, forinstance, by the fee settlement module designating the tax portion as afile from which no fees are to be taken. As requests or attempts aremade to deduct fees from the tax portion, the fee settlement module cannotify a requester of the fee or fees to draw the fee-equivalent fundsfrom one of the alternative sources described above, or to automaticallyprovide the requester with the fee-equivalent funds from the alternativesource. Such collaboration can be prearranged between the merchant,transaction processor (if different than the merchant), the acquirer(s),the issuer, etc., so as to remove any encumbrances from impeding theprocess of successfully isolating the tax portion for settlement withtax account 160.

It should be noted that with any of the above described feereimbursement processes, fees can be reimbursed on a per-fee basis asfees are deducted, or simultaneously in a batch, for example, once allfees have been deducted. Additionally, a batch of fees can be reimbursedfor a single sales transaction or a batch of sales transactions, and feereimbursement batches can be processed immediately or a laterpredetermined time, such as one per day, once per week, etc. Finally, itshould be clear to those of ordinary skill in the art that the abovedescribed fee reimbursement processes can be employed to settle feesassociated with the merchant's account in favor of alternative sourcesas well, for example, when the merchant's fees are paid by a parentcompany or franchisor.

In accordance with further embodiments of the invention, while tax andfee settlements can be enabled on a per-transaction basis or per-batchbasis, transaction reports reflecting the myriad transactions handled bythe transaction processing system can be generated periodically (e.g.,daily, monthly, quarterly, etc.) For example, a merchant employing asoftware program as described above with regard to POS module(s) 112,can generate a transaction report reflecting all the merchant'stransactions handled by the transaction processing system during aparticular period, including all tax and fee related details.

Furthermore, in order to verify that the transaction processing systemis properly processing the merchant transactions, the transactionprocessing system can further include a statement reconciliation module.The statement reconciliation module can be configured to receive two ormore of the following: (a) merchant transaction reports, (b) merchantbank account statements, (c) payment processor reports, and/or (d)Taxing Authority (ACH) bank account statements (or, at minimum, therelevant information reflecting transactions with a particular merchantas provided by the Taxing Authority). The statement reconciliationmodule can compare the different data sets from the variousstatements/reports received, and flag any discrepancies. The statementreconciliation module can be further configured to reconcile anydiscrepancies between the data sets, and report the results to themerchant, payment processor, and/or the Taxing Authority. In doing so,merchants will be assured that they have delivered the correct taxrevenue to the Taxing Authority, the payment processor will be assuredthat all fees have been paid, and the Taxing Authority will be assuredthat it has received the appropriate tax revenue from the merchant.

While certain features of the present invention have been described asoccurring on a particular machine, it would be understood by one ofordinary skill in the art that the functions described herein can beperformed by various machines, interconnected, and distributed over anetwork. The determination of which machines perform specific functionsis determined by the specific software implementation and supportedhardware platforms. Accordingly, the present invention can operate in acentralized environment, wherein a server is responsible forsubstantially all processing, and the clients display the virtualenvironment and communicate user-interaction to the server.Alternatively, the present invention can also be practiced in apeer-to-peer environment having little or no centralized processing,wherein the state of each client is shared with its peers as necessaryand the simulation of the virtual environment is distributed across thepeer network.

While the present invention has been described with respect to certainembodiments thereof, the invention is susceptible to implementation inother ways and manners which are still within the spirit of theinvention. Accordingly, the invention is not limited to the describedembodiments but rather is more broadly defined by the recitations in theclaims appended thereto and equivalents of the recitations therein.

We claim:
 1. A transaction processing system suitable for processing amerchant transaction, the system comprising: a computer having aprocessor, a memory, a first connection over a network for receiving themerchant transaction, and further connections over the network forsettling the merchant transaction; and a separator module comprisingcode which, when executed in the processor, configures the processor toseparate funds associated with the merchant transaction received overthe first connection, the separator module including: a revenuesettlement module operative to configure the processor to settle arevenue portion of the merchant transaction in favor of a first accountaccessible over the network, the first account being associated with themerchant, wherein the revenue portion excludes a tax portion of themerchant transaction; a tax settlement module operative to configure theprocessor to settle the tax portion associated with the merchanttransaction in favor of a second account accessible over the network,the second account being different than the first account; and a feeresolution module operative to configure the processor to resolve atleast one fee associated with operation of the tax settlement module,such that an amount equal to the tax portion is settled in favor of thesecond account.
 2. The transaction processing system as in claim 1,wherein the fee resolution module is configured to appropriate fundsfrom an alternative source equal to the at least one fee; and augmentthe second account with the appropriated funds in the event that the atleast one fee is drawn from either the tax portion or the secondaccount.
 3. The transaction processing system as in claim 2, wherein thealternative source is at least one of the revenue portion, the firstaccount, and a predetermined third account.
 4. The transactionprocessing system as in claim 1, wherein the fee resolution module isconfigured to: isolate the tax portion from being subject to adisbursement of the at least one fee during operation of the taxsettlement module; and discharge the at least one fee by eithernotifying a requester of the at least one fee to draw the at least onefee from an alternative source or by providing the requester with thefee from the alternative source.
 5. The transaction processing system asin claim 4, wherein the alternative source is at least one of therevenue portion, the first account, and a predetermined third account.6. The transaction processing system as in claim 1, wherein the feeresolution module is configured to determine, prior to operation of thetax settlement module, a fee resolution estimate representing an amountestimated to be associated with operation of the tax settlement module;appropriate funds equal to the fee resolution estimate from analternative source; and augment the tax portion with the appropriatedfunds prior to a disbursement of the at least one fee.
 7. Thetransaction processing system as in claim 6, wherein the alternativesource is at least one of the revenue portion, the first account, and apredetermined third account.
 8. The transaction processing system as inclaim 1, wherein the fee resolution module is configured to monitor thesecond account for a predetermined period of time after processing themerchant transaction; and augment the second account with fundsappropriated from an alternative source equal to any fees deducted fromthe second account after processing the merchant transaction.
 9. Thetransaction processing system as in claim 8, wherein the alternativesource is at least one of the revenue portion, the first account, and apredetermined third account.
 10. The transaction processing system as inclaim 1, further configured to settle, by the revenue settlement module,the revenue portion of a plurality of merchant transactionssimultaneously in a batch.
 11. The transaction processing system as inclaim 1, further configured to settle, by the tax settlement module, thetax portion of a plurality of merchant transactions simultaneously in abatch.
 12. A method for providing a transaction processing systemsuitable for processing a merchant transaction, the system including acomputer having a processor, a memory, a first connection over a networkfor receiving the merchant transaction, and further connections over thenetwork for settling the merchant transaction, and a separator modulecomprising code which, when executed in the processor, configures theprocessor to separate funds associated with the merchant transactionreceived over the first connection, the method comprising: settling, bythe separator module executing in the processor, a revenue portion ofthe merchant transaction in favor of a first account accessible over thenetwork, the first account being associated with the merchant, whereinthe revenue portion excludes a tax portion of the merchant transaction;settling, by the separator module executing in the processor, the taxportion associated with the merchant transaction in favor of a secondaccount accessible over the network, the second account being differentthan the first account; and resolving, by the separator module executingin the processor, at least one fee associated with operation of the taxsettlement module, such that an amount equal to the tax portion issettled in favor of the second account.
 13. The method as in claim 12,further comprising appropriating, by the separator module executing inthe processor, funds from an alternative source equal to the at leastone fee; and augmenting the second account with the appropriated fundsin the event that the at least one fee is drawn from either the taxportion or the second account.
 14. The method of claim 13, wherein thealternative source is at least one of the revenue portion, the firstaccount, and a predetermined third account.
 15. The method of claim 12,further comprising: Isolating, by the separator module executing in theprocessor, the tax portion from being subject to a disbursement of theat least one fee during operation of the tax settlement module; anddischarging, by the separator module executing in the processor, the atleast one fee by either notifying a requester of the at least one fee todraw the at least one fee from an alternative source or by providing therequester with the fee from the alternative source.
 16. The method ofclaim 15, wherein the alternative source is at least one of the revenueportion, the first account, and a predetermined third account.
 17. Themethod of claim 12, further comprising determining, by the separatormodule executing in the processor, prior to operation of the taxsettlement module, a fee resolution estimate representing an amountestimated to be associated with operation of the tax settlement module;appropriating funds equal to the fee resolution estimate from analternative source; and augmenting the tax portion with the appropriatedfunds prior to a disbursement of the at least one fee.
 18. The method ofclaim 12, further comprising monitoring, by the separator moduleexecuting in the processor, the second account for a predeterminedperiod of time after processing the merchant transaction; and augmentingthe second account with funds appropriated from an alternative sourceequal to any fees deducted from the second account after processing themerchant transaction.
 19. The method of claim 12, further comprisingsettling, by the separator module executing in the processor, therevenue portion of a plurality of merchant transactions simultaneouslyin a batch.
 20. The method of claim 12, further comprising settling, bythe separator module executing in the processor, the tax portion of aplurality of merchant transactions simultaneously in a batch.